Application Server Performance Recommendations

As the usage and capabilities of the ontrack websites continues to grow, it is important to ensure that the supporting infrastructure is configured and sized appropriately to handle the demand during peak/ busy periods.

As well as considering the database performance recommendations, the application server that hosts the ontrack and web services websites should be considered.

Due to the custom nature of many ontrack websites, and the variance with use from one customer to the next, as well as usage varying so much over the course of the academic year, it is not possible for Tribal to give definitive advice on infrastructure requirements.

However, to offer our customers some guidance, Tribal has conducted some load testing on a standard Ontrack Learner Hub enrolment flow that tests some key components of core ebs functionality.

Test Scenarios

The test scenarios are detailed below.

Enrolment flow

The test scenario for the enrolment flow is as follows:

• Log in to ontrack Learner Hub

• Create an enrolment

• Update learner details

• Update consent information

• Upload evidence

The table Enrolment flow details the server specifications and results from the test scenario.

Enrolment flow

App Server	Database Server	Results
Win2019, x8 CPU, 16GB RAM, Intel Xeon Gold 6246 processor	Win2019, 6x CPU, 64GB RAM	Number of enrolment journeys successfully completed in 60 minutes with a page response time of 3 seconds or less: ebs 4.45.0.1018: 1600 ebs 4.44.0.1063: 1450

Exam results day

The test scenario for exam results day is as follows:

• Directly load Learner Exams page, through the login page, displaying results for 5 exams.

• Tests conducted over a 20 minute period with a 5 minute ramp up and ramp down. That is, 10 minutes under full load.

The table Exam results day details the server specifications and results from the test scenario.

Exam results day

App Server	Database Server	Results
Win2019, x8 CPU, 16GB RAM, Intel Xeon Gold 6246 processor	Win2019, 6x CPU, 64GB RAM	3600 with an average page response time of 3 seconds or less 4400 with an average page response time of 6 seconds or less, using an increased concurrent load

Key Observations

The key observations from our testing are as follows:

• Most load was observed on the web services website – as this is the website that does the ‘heavy lifting’ of exchanging data with the database server and applying business logic.

• Average Application Server memory usage did not significantly increase under load (~6.5 - 8Gb).

• The number of CPU cores was seen to have a significant impact on processing time – 8 Cores gave a page response time that was ~80% faster than when the tests were carried out with 2 Cores.

• The database was ‘comfortable’ under this level of load – averaging 30% CPU load and around 18 - 21Gb Memory.

Tribal next steps

Our intention will be to run these load tests on new versions of ebs and update the metrics on these pages. Our goal will be to increase the number of enrolments that can be processed within an hour.

We will also consider extending our load testing capability to other areas of the product.

Customer Key Recommendation

Our key recommendation for customers is to Focus on the capability of the Web Service tier. You may also want to consider the following suggestions:

• Use a separate set of web services for ontrack Learner Hub and ontrack Hub. This will help spread load, as well as help ensure that a peak load on one website does not impact the other.

• Use a load balancer to create a web-farm of more than one web services website. As well as spreading load, this setup provides resilience from hardware failure on a single server.

• Increase the CPU cores on the application server that hosts the web services, particularly during periods of expected peak demand if using flexible architecture (e.g. Enrolment days).

• Maximise the resources that are available to the web service websites by separating this component from other ebs modules. e.g. Consider installing other modules like Intel and Windows (Workflow) Services onto a separate application server.